Assemblies

Use AnyCPU: All assemblies should be compiled as AnyCPU. The ArchestrA Client Framework (ACF) codebase is designed to be neutral with regard to whether the application runs as 32-bit or 64-bit. Note that the aaClient included with the current ArchestrA Control Framework is a 32-bit process, but a 64-bit version is available on request.

Do not import SDK DLLs with your App: When you import your App into a Galaxy, do not include the ArchestrA Control Framework SDK DLLs with the App DLLs. ACF SDK DLLs are automatically placed in a common location and should not be included with individual Apps.

Dependent files: Include all dependent DLLs and other files in the import folder and avoid external dependencies, such as the Global Assembly Cache (GAC) in the .NET Framework. ArchestrA Control Framework applications are intended to be self-contained and runnable on any machine that includes .Net by x-copying the files. Other external dependencies should hosted by the ArchestrA Service Bus or in a network server to eliminate the need for installation when applications are deployed to target nodes.

Controls

Standard Microsoft Designer Mode: Controls should support the Standard Microsoft Designer Mode for controls. Control instances should be constructed in designer mode within ACF configuration tools when they are imported into the Visualization Repository, and placed into the standard Microsoft Designer Mode when edited. This mode should be taken into account to prevent unintended connections to data sources from occurring while the control is being configured. Determine any required changes in behavior if the host indicates that the control is running in the configuration environment.

IDisposable pattern: If necessary, implement the IDisposable pattern. When the IDisposable pattern is implemented, the ArchestrA Control Framework host calls the Dispose() method on a control’s framework element whenever the control is closed.

Blocking operations: Do not block the UI thread for long operations. The ArchestrA Control Framework supports one thread per top level window. Other controls within the same window may be controlling live information and should not be frozen and made unresponsive because of a blocking operation.

Cross-control communication: Each Screen Layout (top level window) in an ArchestrA application has its own thread. Since controls can only be accessed by callers running on their thread, all cross-control communication must be done using the other control’s dispatcher object. This includes a control accessing its own properties when handling events potentially fired from a different thread.

Use proper encapsulation (public vs private): Ensure that all types defined in App code are appropriately marked as public or private. Only mark as public the controls and control properties that need to be used by consumers.

Filter public controls: Use the AppManifest.xml file to filter out any public controls that should not be visible in the Galaxy Graphics Toolbox. This is useful when third-party DLLs that have public controls are included in the Apps folder, but you do not want those controls to be visible in the Galaxy Graphics Toolbox. You can also use the AppManifest.xml file to filter out public properties on controls.

Specify default Values and categories: Controls should specify default values and categories for their public browsable properties. This is standard for well-behaved controls edited via a property grid. It enables values to be reset to their defaults and show in bold style if edited.

Follow standard exception handling patterns: Refer to the Microsoft guidelines at the following URL: https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/exceptions.

Run-Time Data

Bulk subscribe to references: To read run-time data, subscribe the references in bulk and wait for the data change event, instead of performing an async read for each of the reference.

Versioning

Data files should be versioned properly to support both app updates and backward compatibility; that is, to prevent updates from breaking existing apps.

Version number: The version number should adhere to the format Major.Minor.Patch. For xml files, the version is stored at the root element. For binary files, it should be the first data written to the file stream. Every new release version of the application should be incremented to a higher number.

AppEditor: If an application has its own editor, the editor version must match the application version. See Global App Editor for additional information.